This invention is described in relation to an LDAP (Lightweight Directory Access Protocol) directory server using a relational database as a backing store. This is a particularly appropriate example of hierarchical information which is nonetheless stored in a relational database. It will be seen from the following description, however, that the invention is not restricted to LDAP and is of use wherever hierarchically related objects (data) have to be stored and retrieved from a relational database.
An LDAP directory of the known type comprises a collection of hierarchically related objects, an example of which is shown in FIG. 1. The structure of the directory and content of its objects are typically determined by the contents of a schema object which s normally itself stored in the directory. The contents of this schema object comprise a set of object class definitions and a set of structural rules, as shown for the above example in FIG. 2. The class definitions include a) a list of both mandatory (M) and optional (O) attributes for each object class allowed in the directory; and b) a list defining the hierarchical relationships between object classes and hence the inheritance rules for class definitions. In the above example, all object classes other than top are subclasses of the class top, thus inheriting the attribute objectClass.
The structural rules control the arrangement of objects in the directory hierarchy and comprise a list of the allowed child object classes to each parent class and, for each such combination, the naming attributers) to be used to provide a unique relative distinguished name (RDN) for such an object.
The relative distinguished name (RDN) provides a unique name for an object at that point in the directory hierarchy. Its format is thus somewhat unpredictable for any object, as it is formed by a combination of one or more of the object's attributes and as can be seen from the naming attributes for employees, many different attributes may be used for an object at any one point in the tree. LDAP objects also have a unique name in the directory--the distinguished name (DN). The DN is formed by the successive, sequential concatenation of the RDNs of the object itself and its parents, back up to the root of the directory tree.
Thus, even in the simple case of FIG. 1, the RDN for John Doe may be init=JDD+ID=005047, and the DN may be orgName=IBM, siteName=Arizona, init=JDD+ID=005047; while the RDN for Jane Deer may in fact be emplNate=Jane Deer and the DN may be orgName=IBM, siteName=Arizona, emplName=Jane Deer.
The nature of the LDAP data model means that hierarchies may be varied and complex; similarly the naming scheme for objects as exemplified above also permits substantial variability. As a result, the schema definition itself for a directory does not provide a mechanism that can be easily adapted for storage and access of the directory contents. Consequently a data retrieval system is needed whereby objects can be assigned to a store with indexing to permit subsequent efficient search and retrieval.